The Internet continues to grow and to extend to new geographic locations and new network topologies, using a variety of physical media. The emergence of new network topologies and development of new physical media are parallelled by a continuous quest to improve the performance of the Internet. Developed by the U.S. Department of Defense, TCP is the most common transport layer protocol used on the Internet. TCP is built on top of Internet Protocol (IP) and is nearly always seen in the combination TCP/IP (TCP over IP). The general ability of the Internet to scale to new challenges is a testimony to the robustness and solid design behind the TCP/IP suite of protocols.
IP, upon which the Internet is based, is the protocol by which data is packaged and sent over the Internet. IP forwards each packet of information based on a 4-byte destination address, or IP number. Packets are sent to gateway machines, which route them according to their address. TCP verifies the transmission of the data. TCP adds reliable communication, flow-control, and connection-oriented communication, and provides full-duplex, process-to-process connections. TCP is capable of detecting errors and lost data and of signalling re-transmission of flawed packets, and provides self-clocking, elastic use of available bandwidth, cooperative congestion avoidance, and reliable transmission of datagrams.
By contrast, User Datagram Protocol (UDP) provides an Internet standard network layer, transport layer and session layer protocols which provide simple but unreliable datagram services. UDP is a connectionless protocol which, like TCP, is layered on top of IP. UDP neither guarantees delivery nor does it require a connection. As a result it is lightweight and efficient, but all error processing and re-transmission must be taken care of by the application program.
TCP Tahoe is the earliest implementation of TCP, and is often referred to as a benchmark for performance comparison. Several variants of TCP have emerged including TCP Reno, TCP new-Reno, TCP SACK (Selective Acknowledgment), TCP FACK (Forward Acknowledgment) and TCP Vegas.
The primary objective of these variants is to improve the performance for an individual TCP flow. This objective is achieved by modifying the flow control and congestion avoidance algorithms of TCP to maximize end-to-end TCP performance, while ensuring that the end-hosts behave like good network citizens who try to utilize unused network bandwidth, but also back off when they detect network congestion.
Generally, these prior art TCP schemes use cumulative acknowledgments, also known as ACKs, for error recovery and congestion control. In a simplified example, sequential data packets are sent from a transmitting host to a receiving host. As each packet is received at the receiving host, the receiving host sends an acknowledgment back to the transmitting host. If an error, such as a dropped packet, has occurred, the transmitting host will not receive an acknowledgment for that packet. In such a situation, the transmitting host then re-transmits the dropped packet. Where a number of acknowledgments are not received, TCP assumes that the network is congested, and decreases the transmission rate, or congestion window. Recent TCP implementations permit a receiver to send an acknowledgment that covers multiple received packets.
Recent studies of Internet traffic have shown that a significant percentage (up to 40%) of packets on the Internet contain zero bytes of data, or, in other words, contain only control information. Since up to 95% of network packets are TCP, it can be assumed that these control packets are mainly TCP acknowledgments and other TCP control packets, such as synchronization messages (SYN), and finish transmit messages (FIN). If we conservatively assume that two third of the control packets are acknowledgments, then approximately 26% of all network traffic is acknowledgments. This is a significant proportion of the packets on the network.
While acknowledgments constitute a large percentage of the packets on the Internet, it is possible to argue that they do not consume a large percentage of the bandwidth and, therefore, do not pose much of a performance concern. However, although the acknowledgments do not utilize a significant part of the bandwidth on the network, they can be problematic for a number of reasons. Acknowledgments consume significant resources in terms of load network devices, such as routers. While the network devices have less processing to do on the small acknowledgment packets, there is still a base set of resources consumed by each packet that passes through such devices, regardless of packet size. The end result of this is that the router can handle less data packets due to the load of control traffic.
Acknowledgments are susceptible to a phenomenon referred to as acknowledgment compression. This causes a bursty TCP sending pattern, and contributes to congestion and degraded performance for TCP flows. This is particularly true for asymmetric links, such as wireless, Asynchronous Digital Subscriber Line (ADSL) and satellite, where acknowledgments are transmitted at lower bandwidth rates than the data sending rates.
Acknowledgments also pose a problem in the emerging Differentiated Services IP Quality of Service (QoS) networks. In such a network, packets are explicitly marked for preferential treatment. The presence of an acknowledgment-based scheme implies that priority-marking must be performed by edge devices at both the sender and the receiver. This implies the need for double-ended Service Level Agreements (SLA), which are not viable on a large scale Internet. Further, it raises issues of scalability and an increased level of control traffic.
Finally, acknowledgments are a significant overhead for the large emerging market of low-power wireless devices such as personal digital assistants (PDA). Acknowledgment control traffic use valuable and limited resources on such devices.
It is therefore desirable to provide a system and method to reduce acknowledgment traffic generated by TCP. It is further desirable to provide a system and method for error recovery and congestion control that does not require acknowledgments.